home *** CD-ROM | disk | FTP | other *** search
/ Scene Storm / Scene Storm - Volume 1.iso / coding / tools / gcc / gcc270_src.lha / gcc-2.7.0-amiga / gcc.info-13 < prev    next >
Encoding:
GNU Info File  |  1995-06-16  |  49.1 KB  |  1,145 lines

  1. This is Info file gcc.info, produced by Makeinfo-1.55 from the input
  2. file gcc.texi.
  3.  
  4.    This file documents the use and the internals of the GNU compiler.
  5.  
  6.    Published by the Free Software Foundation 59 Temple Place - Suite 330
  7. Boston, MA 02111-1307 USA
  8.  
  9.    Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software
  10. Foundation, Inc.
  11.  
  12.    Permission is granted to make and distribute verbatim copies of this
  13. manual provided the copyright notice and this permission notice are
  14. preserved on all copies.
  15.  
  16.    Permission is granted to copy and distribute modified versions of
  17. this manual under the conditions for verbatim copying, provided also
  18. that the sections entitled "GNU General Public License," "Funding for
  19. Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
  20. included exactly as in the original, and provided that the entire
  21. resulting derived work is distributed under the terms of a permission
  22. notice identical to this one.
  23.  
  24.    Permission is granted to copy and distribute translations of this
  25. manual into another language, under the above conditions for modified
  26. versions, except that the sections entitled "GNU General Public
  27. License," "Funding for Free Software," and "Protect Your Freedom--Fight
  28. `Look And Feel'", and this permission notice, may be included in
  29. translations approved by the Free Software Foundation instead of in the
  30. original English.
  31.  
  32. 
  33. File: gcc.info,  Node: Interface,  Next: Passes,  Prev: Portability,  Up: Top
  34.  
  35. Interfacing to GNU CC Output
  36. ****************************
  37.  
  38.    GNU CC is normally configured to use the same function calling
  39. convention normally in use on the target system.  This is done with the
  40. machine-description macros described (*note Target Macros::.).
  41.  
  42.    However, returning of structure and union values is done differently
  43. on some target machines.  As a result, functions compiled with PCC
  44. returning such types cannot be called from code compiled with GNU CC,
  45. and vice versa.  This does not cause trouble often because few Unix
  46. library routines return structures or unions.
  47.  
  48.    GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes
  49. long in the same registers used for `int' or `double' return values.
  50. (GNU CC typically allocates variables of such types in registers also.)
  51. Structures and unions of other sizes are returned by storing them into
  52. an address passed by the caller (usually in a register).  The
  53. machine-description macros `STRUCT_VALUE' and `STRUCT_INCOMING_VALUE'
  54. tell GNU CC where to pass this address.
  55.  
  56.    By contrast, PCC on most target machines returns structures and
  57. unions of any size by copying the data into an area of static storage,
  58. and then returning the address of that storage as if it were a pointer
  59. value.  The caller must copy the data from that memory area to the
  60. place where the value is wanted.  This is slower than the method used
  61. by GNU CC, and fails to be reentrant.
  62.  
  63.    On some target machines, such as RISC machines and the 80386, the
  64. standard system convention is to pass to the subroutine the address of
  65. where to return the value.  On these machines, GNU CC has been
  66. configured to be compatible with the standard compiler, when this method
  67. is used.  It may not be compatible for structures of 1, 2, 4 or 8 bytes.
  68.  
  69.    GNU CC uses the system's standard convention for passing arguments.
  70. On some machines, the first few arguments are passed in registers; in
  71. others, all are passed on the stack.  It would be possible to use
  72. registers for argument passing on any machine, and this would probably
  73. result in a significant speedup.  But the result would be complete
  74. incompatibility with code that follows the standard convention.  So this
  75. change is practical only if you are switching to GNU CC as the sole C
  76. compiler for the system.  We may implement register argument passing on
  77. certain machines once we have a complete GNU system so that we can
  78. compile the libraries with GNU CC.
  79.  
  80.    On some machines (particularly the Sparc), certain types of arguments
  81. are passed "by invisible reference".  This means that the value is
  82. stored in memory, and the address of the memory location is passed to
  83. the subroutine.
  84.  
  85.    If you use `longjmp', beware of automatic variables.  ANSI C says
  86. that automatic variables that are not declared `volatile' have undefined
  87. values after a `longjmp'.  And this is all GNU CC promises to do,
  88. because it is very difficult to restore register variables correctly,
  89. and one of GNU CC's features is that it can put variables in registers
  90. without your asking it to.
  91.  
  92.    If you want a variable to be unaltered by `longjmp', and you don't
  93. want to write `volatile' because old C compilers don't accept it, just
  94. take the address of the variable.  If a variable's address is ever
  95. taken, even if just to compute it and ignore it, then the variable
  96. cannot go in a register:
  97.  
  98.      {
  99.        int careful;
  100.        &careful;
  101.        ...
  102.      }
  103.  
  104.    Code compiled with GNU CC may call certain library routines.  Most of
  105. them handle arithmetic for which there are no instructions.  This
  106. includes multiply and divide on some machines, and floating point
  107. operations on any machine for which floating point support is disabled
  108. with `-msoft-float'.  Some standard parts of the C library, such as
  109. `bcopy' or `memcpy', are also called automatically.  The usual function
  110. call interface is used for calling the library routines.
  111.  
  112.    These library routines should be defined in the library `libgcc.a',
  113. which GNU CC automatically searches whenever it links a program.  On
  114. machines that have multiply and divide instructions, if hardware
  115. floating point is in use, normally `libgcc.a' is not needed, but it is
  116. searched just in case.
  117.  
  118.    Each arithmetic function is defined in `libgcc1.c' to use the
  119. corresponding C arithmetic operator.  As long as the file is compiled
  120. with another C compiler, which supports all the C arithmetic operators,
  121. this file will work portably.  However, `libgcc1.c' does not work if
  122. compiled with GNU CC, because each arithmetic function would compile
  123. into a call to itself!
  124.  
  125. 
  126. File: gcc.info,  Node: Passes,  Next: RTL,  Prev: Interface,  Up: Top
  127.  
  128. Passes and Files of the Compiler
  129. ********************************
  130.  
  131.    The overall control structure of the compiler is in `toplev.c'.  This
  132. file is responsible for initialization, decoding arguments, opening and
  133. closing files, and sequencing the passes.
  134.  
  135.    The parsing pass is invoked only once, to parse the entire input.
  136. The RTL intermediate code for a function is generated as the function
  137. is parsed, a statement at a time.  Each statement is read in as a
  138. syntax tree and then converted to RTL; then the storage for the tree
  139. for the statement is reclaimed.  Storage for types (and the expressions
  140. for their sizes), declarations, and a representation of the binding
  141. contours and how they nest, remain until the function is finished being
  142. compiled; these are all needed to output the debugging information.
  143.  
  144.    Each time the parsing pass reads a complete function definition or
  145. top-level declaration, it calls either the function
  146. `rest_of_compilation', or the function `rest_of_decl_compilation' in
  147. `toplev.c', which are responsible for all further processing necessary,
  148. ending with output of the assembler language.  All other compiler
  149. passes run, in sequence, within `rest_of_compilation'.  When that
  150. function returns from compiling a function definition, the storage used
  151. for that function definition's compilation is entirely freed, unless it
  152. is an inline function (*note An Inline Function is As Fast As a Macro:
  153. Inline.).
  154.  
  155.    Here is a list of all the passes of the compiler and their source
  156. files.  Also included is a description of where debugging dumps can be
  157. requested with `-d' options.
  158.  
  159.    * Parsing.  This pass reads the entire text of a function definition,
  160.      constructing partial syntax trees.  This and RTL generation are no
  161.      longer truly separate passes (formerly they were), but it is
  162.      easier to think of them as separate.
  163.  
  164.      The tree representation does not entirely follow C syntax, because
  165.      it is intended to support other languages as well.
  166.  
  167.      Language-specific data type analysis is also done in this pass,
  168.      and every tree node that represents an expression has a data type
  169.      attached.  Variables are represented as declaration nodes.
  170.  
  171.      Constant folding and some arithmetic simplifications are also done
  172.      during this pass.
  173.  
  174.      The language-independent source files for parsing are
  175.      `stor-layout.c', `fold-const.c', and `tree.c'.  There are also
  176.      header files `tree.h' and `tree.def' which define the format of
  177.      the tree representation.
  178.  
  179.      The source files to parse C are `c-parse.in', `c-decl.c',
  180.      `c-typeck.c', `c-aux-info.c', `c-convert.c', and `c-lang.c' along
  181.      with header files `c-lex.h', and `c-tree.h'.
  182.  
  183.      The source files for parsing C++ are `cp-parse.y', `cp-class.c',
  184.      `cp-cvt.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c',
  185.      `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c',
  186.      `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along
  187.      with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'.
  188.  
  189.      The special source files for parsing Objective C are
  190.      `objc-parse.y', `objc-actions.c', `objc-tree.def', and
  191.      `objc-actions.h'.  Certain C-specific files are used for this as
  192.      well.
  193.  
  194.      The file `c-common.c' is also used for all of the above languages.
  195.  
  196.    * RTL generation.  This is the conversion of syntax tree into RTL
  197.      code.  It is actually done statement-by-statement during parsing,
  198.      but for most purposes it can be thought of as a separate pass.
  199.  
  200.      This is where the bulk of target-parameter-dependent code is found,
  201.      since often it is necessary for strategies to apply only when
  202.      certain standard kinds of instructions are available.  The purpose
  203.      of named instruction patterns is to provide this information to
  204.      the RTL generation pass.
  205.  
  206.      Optimization is done in this pass for `if'-conditions that are
  207.      comparisons, boolean operations or conditional expressions.  Tail
  208.      recursion is detected at this time also.  Decisions are made about
  209.      how best to arrange loops and how to output `switch' statements.
  210.  
  211.      The source files for RTL generation include `stmt.c', `calls.c',
  212.      `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and
  213.      `emit-rtl.c'.  Also, the file `insn-emit.c', generated from the
  214.      machine description by the program `genemit', is used in this
  215.      pass.  The header file `expr.h' is used for communication within
  216.      this pass.
  217.  
  218.      The header files `insn-flags.h' and `insn-codes.h', generated from
  219.      the machine description by the programs `genflags' and `gencodes',
  220.      tell this pass which standard names are available for use and
  221.      which patterns correspond to them.
  222.  
  223.      Aside from debugging information output, none of the following
  224.      passes refers to the tree structure representation of the function
  225.      (only part of which is saved).
  226.  
  227.      The decision of whether the function can and should be expanded
  228.      inline in its subsequent callers is made at the end of rtl
  229.      generation.  The function must meet certain criteria, currently
  230.      related to the size of the function and the types and number of
  231.      parameters it has.  Note that this function may contain loops,
  232.      recursive calls to itself (tail-recursive functions can be
  233.      inlined!), gotos, in short, all constructs supported by GNU CC.
  234.      The file `integrate.c' contains the code to save a function's rtl
  235.      for later inlining and to inline that rtl when the function is
  236.      called.  The header file `integrate.h' is also used for this
  237.      purpose.
  238.  
  239.      The option `-dr' causes a debugging dump of the RTL code after
  240.      this pass.  This dump file's name is made by appending `.rtl' to
  241.      the input file name.
  242.  
  243.    * Jump optimization.  This pass simplifies jumps to the following
  244.      instruction, jumps across jumps, and jumps to jumps.  It deletes
  245.      unreferenced labels and unreachable code, except that unreachable
  246.      code that contains a loop is not recognized as unreachable in this
  247.      pass.  (Such loops are deleted later in the basic block analysis.)
  248.      It also converts some code originally written with jumps into
  249.      sequences of instructions that directly set values from the
  250.      results of comparisons, if the machine has such instructions.
  251.  
  252.      Jump optimization is performed two or three times.  The first time
  253.      is immediately following RTL generation.  The second time is after
  254.      CSE, but only if CSE says repeated jump optimization is needed.
  255.      The last time is right before the final pass.  That time,
  256.      cross-jumping and deletion of no-op move instructions are done
  257.      together with the optimizations described above.
  258.  
  259.      The source file of this pass is `jump.c'.
  260.  
  261.      The option `-dj' causes a debugging dump of the RTL code after
  262.      this pass is run for the first time.  This dump file's name is
  263.      made by appending `.jump' to the input file name.
  264.  
  265.    * Register scan.  This pass finds the first and last use of each
  266.      register, as a guide for common subexpression elimination.  Its
  267.      source is in `regclass.c'.
  268.  
  269.    * Jump threading.  This pass detects a condition jump that branches
  270.      to an identical or inverse test.  Such jumps can be `threaded'
  271.      through the second conditional test.  The source code for this
  272.      pass is in `jump.c'.  This optimization is only performed if
  273.      `-fthread-jumps' is enabled.
  274.  
  275.    * Common subexpression elimination.  This pass also does constant
  276.      propagation.  Its source file is `cse.c'.  If constant propagation
  277.      causes conditional jumps to become unconditional or to become
  278.      no-ops, jump optimization is run again when CSE is finished.
  279.  
  280.      The option `-ds' causes a debugging dump of the RTL code after
  281.      this pass.  This dump file's name is made by appending `.cse' to
  282.      the input file name.
  283.  
  284.    * Loop optimization.  This pass moves constant expressions out of
  285.      loops, and optionally does strength-reduction and loop unrolling
  286.      as well.  Its source files are `loop.c' and `unroll.c', plus the
  287.      header `loop.h' used for communication between them.  Loop
  288.      unrolling uses some functions in `integrate.c' and the header
  289.      `integrate.h'.
  290.  
  291.      The option `-dL' causes a debugging dump of the RTL code after
  292.      this pass.  This dump file's name is made by appending `.loop' to
  293.      the input file name.
  294.  
  295.    * If `-frerun-cse-after-loop' was enabled, a second common
  296.      subexpression elimination pass is performed after the loop
  297.      optimization pass.  Jump threading is also done again at this time
  298.      if it was specified.
  299.  
  300.      The option `-dt' causes a debugging dump of the RTL code after
  301.      this pass.  This dump file's name is made by appending `.cse2' to
  302.      the input file name.
  303.  
  304.    * Stupid register allocation is performed at this point in a
  305.      nonoptimizing compilation.  It does a little data flow analysis as
  306.      well.  When stupid register allocation is in use, the next pass
  307.      executed is the reloading pass; the others in between are skipped.
  308.      The source file is `stupid.c'.
  309.  
  310.    * Data flow analysis (`flow.c').  This pass divides the program into
  311.      basic blocks (and in the process deletes unreachable loops); then
  312.      it computes which pseudo-registers are live at each point in the
  313.      program, and makes the first instruction that uses a value point at
  314.      the instruction that computed the value.
  315.  
  316.      This pass also deletes computations whose results are never used,
  317.      and combines memory references with add or subtract instructions
  318.      to make autoincrement or autodecrement addressing.
  319.  
  320.      The option `-df' causes a debugging dump of the RTL code after
  321.      this pass.  This dump file's name is made by appending `.flow' to
  322.      the input file name.  If stupid register allocation is in use, this
  323.      dump file reflects the full results of such allocation.
  324.  
  325.    * Instruction combination (`combine.c').  This pass attempts to
  326.      combine groups of two or three instructions that are related by
  327.      data flow into single instructions.  It combines the RTL
  328.      expressions for the instructions by substitution, simplifies the
  329.      result using algebra, and then attempts to match the result
  330.      against the machine description.
  331.  
  332.      The option `-dc' causes a debugging dump of the RTL code after
  333.      this pass.  This dump file's name is made by appending `.combine'
  334.      to the input file name.
  335.  
  336.    * Instruction scheduling (`sched.c').  This pass looks for
  337.      instructions whose output will not be available by the time that
  338.      it is used in subsequent instructions.  (Memory loads and floating
  339.      point instructions often have this behavior on RISC machines).  It
  340.      re-orders instructions within a basic block to try to separate the
  341.      definition and use of items that otherwise would cause pipeline
  342.      stalls.
  343.  
  344.      Instruction scheduling is performed twice.  The first time is
  345.      immediately after instruction combination and the second is
  346.      immediately after reload.
  347.  
  348.      The option `-dS' causes a debugging dump of the RTL code after this
  349.      pass is run for the first time.  The dump file's name is made by
  350.      appending `.sched' to the input file name.
  351.  
  352.    * Register class preferencing.  The RTL code is scanned to find out
  353.      which register class is best for each pseudo register.  The source
  354.      file is `regclass.c'.
  355.  
  356.    * Local register allocation (`local-alloc.c').  This pass allocates
  357.      hard registers to pseudo registers that are used only within one
  358.      basic block.  Because the basic block is linear, it can use fast
  359.      and powerful techniques to do a very good job.
  360.  
  361.      The option `-dl' causes a debugging dump of the RTL code after
  362.      this pass.  This dump file's name is made by appending `.lreg' to
  363.      the input file name.
  364.  
  365.    * Global register allocation (`global.c').  This pass allocates hard
  366.      registers for the remaining pseudo registers (those whose life
  367.      spans are not contained in one basic block).
  368.  
  369.    * Reloading.  This pass renumbers pseudo registers with the hardware
  370.      registers numbers they were allocated.  Pseudo registers that did
  371.      not get hard registers are replaced with stack slots.  Then it
  372.      finds instructions that are invalid because a value has failed to
  373.      end up in a register, or has ended up in a register of the wrong
  374.      kind.  It fixes up these instructions by reloading the
  375.      problematical values temporarily into registers.  Additional
  376.      instructions are generated to do the copying.
  377.  
  378.      The reload pass also optionally eliminates the frame pointer and
  379.      inserts instructions to save and restore call-clobbered registers
  380.      around calls.
  381.  
  382.      Source files are `reload.c' and `reload1.c', plus the header
  383.      `reload.h' used for communication between them.
  384.  
  385.      The option `-dg' causes a debugging dump of the RTL code after
  386.      this pass.  This dump file's name is made by appending `.greg' to
  387.      the input file name.
  388.  
  389.    * Instruction scheduling is repeated here to try to avoid pipeline
  390.      stalls due to memory loads generated for spilled pseudo registers.
  391.  
  392.      The option `-dR' causes a debugging dump of the RTL code after
  393.      this pass.  This dump file's name is made by appending `.sched2'
  394.      to the input file name.
  395.  
  396.    * Jump optimization is repeated, this time including cross-jumping
  397.      and deletion of no-op move instructions.
  398.  
  399.      The option `-dJ' causes a debugging dump of the RTL code after
  400.      this pass.  This dump file's name is made by appending `.jump2' to
  401.      the input file name.
  402.  
  403.    * Delayed branch scheduling.  This optional pass attempts to find
  404.      instructions that can go into the delay slots of other
  405.      instructions, usually jumps and calls.  The source file name is
  406.      `reorg.c'.
  407.  
  408.      The option `-dd' causes a debugging dump of the RTL code after
  409.      this pass.  This dump file's name is made by appending `.dbr' to
  410.      the input file name.
  411.  
  412.    * Conversion from usage of some hard registers to usage of a register
  413.      stack may be done at this point.  Currently, this is supported only
  414.      for the floating-point registers of the Intel 80387 coprocessor.
  415.      The source file name is `reg-stack.c'.
  416.  
  417.      The options `-dk' causes a debugging dump of the RTL code after
  418.      this pass.  This dump file's name is made by appending `.stack' to
  419.      the input file name.
  420.  
  421.    * Final.  This pass outputs the assembler code for the function.  It
  422.      is also responsible for identifying spurious test and compare
  423.      instructions.  Machine-specific peephole optimizations are
  424.      performed at the same time.  The function entry and exit sequences
  425.      are generated directly as assembler code in this pass; they never
  426.      exist as RTL.
  427.  
  428.      The source files are `final.c' plus `insn-output.c'; the latter is
  429.      generated automatically from the machine description by the tool
  430.      `genoutput'.  The header file `conditions.h' is used for
  431.      communication between these files.
  432.  
  433.    * Debugging information output.  This is run after final because it
  434.      must output the stack slot offsets for pseudo registers that did
  435.      not get hard registers.  Source files are `dbxout.c' for DBX
  436.      symbol table format, `sdbout.c' for SDB symbol table format, and
  437.      `dwarfout.c' for DWARF symbol table format.
  438.  
  439.    Some additional files are used by all or many passes:
  440.  
  441.    * Every pass uses `machmode.def' and `machmode.h' which define the
  442.      machine modes.
  443.  
  444.    * Several passes use `real.h', which defines the default
  445.      representation of floating point constants and how to operate on
  446.      them.
  447.  
  448.    * All the passes that work with RTL use the header files `rtl.h' and
  449.      `rtl.def', and subroutines in file `rtl.c'.  The tools `gen*' also
  450.      use these files to read and work with the machine description RTL.
  451.  
  452.    * Several passes refer to the header file `insn-config.h' which
  453.      contains a few parameters (C macro definitions) generated
  454.      automatically from the machine description RTL by the tool
  455.      `genconfig'.
  456.  
  457.    * Several passes use the instruction recognizer, which consists of
  458.      `recog.c' and `recog.h', plus the files `insn-recog.c' and
  459.      `insn-extract.c' that are generated automatically from the machine
  460.      description by the tools `genrecog' and `genextract'.
  461.  
  462.    * Several passes use the header files `regs.h' which defines the
  463.      information recorded about pseudo register usage, and
  464.      `basic-block.h' which defines the information recorded about basic
  465.      blocks.
  466.  
  467.    * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector
  468.      with a bit for each hard register, and some macros to manipulate
  469.      it.  This type is just `int' if the machine has few enough hard
  470.      registers; otherwise it is an array of `int' and some of the
  471.      macros expand into loops.
  472.  
  473.    * Several passes use instruction attributes.  A definition of the
  474.      attributes defined for a particular machine is in file
  475.      `insn-attr.h', which is generated from the machine description by
  476.      the program `genattr'.  The file `insn-attrtab.c' contains
  477.      subroutines to obtain the attribute values for insns.  It is
  478.      generated from the machine description by the program `genattrtab'.
  479.  
  480. 
  481. File: gcc.info,  Node: RTL,  Next: Machine Desc,  Prev: Passes,  Up: Top
  482.  
  483. RTL Representation
  484. ******************
  485.  
  486.    Most of the work of the compiler is done on an intermediate
  487. representation called register transfer language.  In this language,
  488. the instructions to be output are described, pretty much one by one, in
  489. an algebraic form that describes what the instruction does.
  490.  
  491.    RTL is inspired by Lisp lists.  It has both an internal form, made
  492. up of structures that point at other structures, and a textual form
  493. that is used in the machine description and in printed debugging dumps.
  494. The textual form uses nested parentheses to indicate the pointers in
  495. the internal form.
  496.  
  497. * Menu:
  498.  
  499. * RTL Objects::       Expressions vs vectors vs strings vs integers.
  500. * Accessors::         Macros to access expression operands or vector elts.
  501. * Flags::             Other flags in an RTL expression.
  502. * Machine Modes::     Describing the size and format of a datum.
  503. * Constants::         Expressions with constant values.
  504. * Regs and Memory::   Expressions representing register contents or memory.
  505. * Arithmetic::        Expressions representing arithmetic on other expressions.
  506. * Comparisons::       Expressions representing comparison of expressions.
  507. * Bit Fields::        Expressions representing bitfields in memory or reg.
  508. * Conversions::       Extending, truncating, floating or fixing.
  509. * RTL Declarations::  Declaring volatility, constancy, etc.
  510. * Side Effects::      Expressions for storing in registers, etc.
  511. * Incdec::            Embedded side-effects for autoincrement addressing.
  512. * Assembler::         Representing `asm' with operands.
  513. * Insns::             Expression types for entire insns.
  514. * Calls::             RTL representation of function call insns.
  515. * Sharing::           Some expressions are unique; others *must* be copied.
  516. * Reading RTL::       Reading textual RTL from a file.
  517.  
  518. 
  519. File: gcc.info,  Node: RTL Objects,  Next: Accessors,  Prev: RTL,  Up: RTL
  520.  
  521. RTL Object Types
  522. ================
  523.  
  524.    RTL uses five kinds of objects: expressions, integers, wide integers,
  525. strings and vectors.  Expressions are the most important ones.  An RTL
  526. expression ("RTX", for short) is a C structure, but it is usually
  527. referred to with a pointer; a type that is given the typedef name `rtx'.
  528.  
  529.    An integer is simply an `int'; their written form uses decimal
  530. digits.  A wide integer is an integral object whose type is
  531. `HOST_WIDE_INT' (*note Config::.); their written form uses decimal
  532. digits.
  533.  
  534.    A string is a sequence of characters.  In core it is represented as a
  535. `char *' in usual C fashion, and it is written in C syntax as well.
  536. However, strings in RTL may never be null.  If you write an empty
  537. string in a machine description, it is represented in core as a null
  538. pointer rather than as a pointer to a null character.  In certain
  539. contexts, these null pointers instead of strings are valid.  Within RTL
  540. code, strings are most commonly found inside `symbol_ref' expressions,
  541. but they appear in other contexts in the RTL expressions that make up
  542. machine descriptions.
  543.  
  544.    A vector contains an arbitrary number of pointers to expressions.
  545. The number of elements in the vector is explicitly present in the
  546. vector.  The written form of a vector consists of square brackets
  547. (`[...]') surrounding the elements, in sequence and with whitespace
  548. separating them.  Vectors of length zero are not created; null pointers
  549. are used instead.
  550.  
  551.    Expressions are classified by "expression codes" (also called RTX
  552. codes).  The expression code is a name defined in `rtl.def', which is
  553. also (in upper case) a C enumeration constant.  The possible expression
  554. codes and their meanings are machine-independent.  The code of an RTX
  555. can be extracted with the macro `GET_CODE (X)' and altered with
  556. `PUT_CODE (X, NEWCODE)'.
  557.  
  558.    The expression code determines how many operands the expression
  559. contains, and what kinds of objects they are.  In RTL, unlike Lisp, you
  560. cannot tell by looking at an operand what kind of object it is.
  561. Instead, you must know from its context--from the expression code of
  562. the containing expression.  For example, in an expression of code
  563. `subreg', the first operand is to be regarded as an expression and the
  564. second operand as an integer.  In an expression of code `plus', there
  565. are two operands, both of which are to be regarded as expressions.  In
  566. a `symbol_ref' expression, there is one operand, which is to be
  567. regarded as a string.
  568.  
  569.    Expressions are written as parentheses containing the name of the
  570. expression type, its flags and machine mode if any, and then the
  571. operands of the expression (separated by spaces).
  572.  
  573.    Expression code names in the `md' file are written in lower case,
  574. but when they appear in C code they are written in upper case.  In this
  575. manual, they are shown as follows: `const_int'.
  576.  
  577.    In a few contexts a null pointer is valid where an expression is
  578. normally wanted.  The written form of this is `(nil)'.
  579.  
  580. 
  581. File: gcc.info,  Node: Accessors,  Next: Flags,  Prev: RTL Objects,  Up: RTL
  582.  
  583. Access to Operands
  584. ==================
  585.  
  586.    For each expression type `rtl.def' specifies the number of contained
  587. objects and their kinds, with four possibilities: `e' for expression
  588. (actually a pointer to an expression), `i' for integer, `w' for wide
  589. integer, `s' for string, and `E' for vector of expressions.  The
  590. sequence of letters for an expression code is called its "format".
  591. Thus, the format of `subreg' is `ei'.
  592.  
  593.    A few other format characters are used occasionally:
  594.  
  595. `u'
  596.      `u' is equivalent to `e' except that it is printed differently in
  597.      debugging dumps.  It is used for pointers to insns.
  598.  
  599. `n'
  600.      `n' is equivalent to `i' except that it is printed differently in
  601.      debugging dumps.  It is used for the line number or code number of
  602.      a `note' insn.
  603.  
  604. `S'
  605.      `S' indicates a string which is optional.  In the RTL objects in
  606.      core, `S' is equivalent to `s', but when the object is read, from
  607.      an `md' file, the string value of this operand may be omitted.  An
  608.      omitted string is taken to be the null string.
  609.  
  610. `V'
  611.      `V' indicates a vector which is optional.  In the RTL objects in
  612.      core, `V' is equivalent to `E', but when the object is read from
  613.      an `md' file, the vector value of this operand may be omitted.  An
  614.      omitted vector is effectively the same as a vector of no elements.
  615.  
  616. `0'
  617.      `0' means a slot whose contents do not fit any normal category.
  618.      `0' slots are not printed at all in dumps, and are often used in
  619.      special ways by small parts of the compiler.
  620.  
  621.    There are macros to get the number of operands, the format, and the
  622. class of an expression code:
  623.  
  624. `GET_RTX_LENGTH (CODE)'
  625.      Number of operands of an RTX of code CODE.
  626.  
  627. `GET_RTX_FORMAT (CODE)'
  628.      The format of an RTX of code CODE, as a C string.
  629.  
  630. `GET_RTX_CLASS (CODE)'
  631.      A single character representing the type of RTX operation that code
  632.      CODE performs.
  633.  
  634.      The following classes are defined:
  635.  
  636.     `o'
  637.           An RTX code that represents an actual object, such as `reg' or
  638.           `mem'.  `subreg' is not in this class.
  639.  
  640.     `<'
  641.           An RTX code for a comparison.  The codes in this class are
  642.           `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU',
  643.           `GTU'.
  644.  
  645.     `1'
  646.           An RTX code for a unary arithmetic operation, such as `neg'.
  647.  
  648.     `c'
  649.           An RTX code for a commutative binary operation, other than
  650.           `NE' and `EQ' (which have class `<').
  651.  
  652.     `2'
  653.           An RTX code for a noncommutative binary operation, such as
  654.           `MINUS'.
  655.  
  656.     `b'
  657.           An RTX code for a bitfield operation, either `ZERO_EXTRACT' or
  658.           `SIGN_EXTRACT'.
  659.  
  660.     `3'
  661.           An RTX code for other three input operations, such as
  662.           `IF_THEN_ELSE'.
  663.  
  664.     `i'
  665.           An RTX code for a machine insn (`INSN', `JUMP_INSN', and
  666.           `CALL_INSN').
  667.  
  668.     `m'
  669.           An RTX code for something that matches in insns, such as
  670.           `MATCH_DUP'.
  671.  
  672.     `x'
  673.           All other RTX codes.
  674.  
  675.    Operands of expressions are accessed using the macros `XEXP',
  676. `XINT', `XWINT' and `XSTR'.  Each of these macros takes two arguments:
  677. an expression-pointer (RTX) and an operand number (counting from zero).
  678. Thus,
  679.  
  680.      XEXP (X, 2)
  681.  
  682. accesses operand 2 of expression X, as an expression.
  683.  
  684.      XINT (X, 2)
  685.  
  686. accesses the same operand as an integer.  `XSTR', used in the same
  687. fashion, would access it as a string.
  688.  
  689.    Any operand can be accessed as an integer, as an expression or as a
  690. string.  You must choose the correct method of access for the kind of
  691. value actually stored in the operand.  You would do this based on the
  692. expression code of the containing expression.  That is also how you
  693. would know how many operands there are.
  694.  
  695.    For example, if X is a `subreg' expression, you know that it has two
  696. operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
  697. 1)'.  If you did `XINT (X, 0)', you would get the address of the
  698. expression operand but cast as an integer; that might occasionally be
  699. useful, but it would be cleaner to write `(int) XEXP (X, 0)'.  `XEXP
  700. (X, 1)' would also compile without error, and would return the second,
  701. integer operand cast as an expression pointer, which would probably
  702. result in a crash when accessed.  Nothing stops you from writing `XEXP
  703. (X, 28)' either, but this will access memory past the end of the
  704. expression with unpredictable results.
  705.  
  706.    Access to operands which are vectors is more complicated.  You can
  707. use the macro `XVEC' to get the vector-pointer itself, or the macros
  708. `XVECEXP' and `XVECLEN' to access the elements and length of a vector.
  709.  
  710. `XVEC (EXP, IDX)'
  711.      Access the vector-pointer which is operand number IDX in EXP.
  712.  
  713. `XVECLEN (EXP, IDX)'
  714.      Access the length (number of elements) in the vector which is in
  715.      operand number IDX in EXP.  This value is an `int'.
  716.  
  717. `XVECEXP (EXP, IDX, ELTNUM)'
  718.      Access element number ELTNUM in the vector which is in operand
  719.      number IDX in EXP.  This value is an RTX.
  720.  
  721.      It is up to you to make sure that ELTNUM is not negative and is
  722.      less than `XVECLEN (EXP, IDX)'.
  723.  
  724.    All the macros defined in this section expand into lvalues and
  725. therefore can be used to assign the operands, lengths and vector
  726. elements as well as to access them.
  727.  
  728. 
  729. File: gcc.info,  Node: Flags,  Next: Machine Modes,  Prev: Accessors,  Up: RTL
  730.  
  731. Flags in an RTL Expression
  732. ==========================
  733.  
  734.    RTL expressions contain several flags (one-bit bitfields) that are
  735. used in certain types of expression.  Most often they are accessed with
  736. the following macros:
  737.  
  738. `MEM_VOLATILE_P (X)'
  739.      In `mem' expressions, nonzero for volatile memory references.
  740.      Stored in the `volatil' field and printed as `/v'.
  741.  
  742. `MEM_IN_STRUCT_P (X)'
  743.      In `mem' expressions, nonzero for reference to an entire
  744.      structure, union or array, or to a component of one.  Zero for
  745.      references to a scalar variable or through a pointer to a scalar.
  746.      Stored in the `in_struct' field and printed as `/s'.
  747.  
  748. `REG_LOOP_TEST_P'
  749.      In `reg' expressions, nonzero if this register's entire life is
  750.      contained in the exit test code for some loop.  Stored in the
  751.      `in_struct' field and printed as `/s'.
  752.  
  753. `REG_USERVAR_P (X)'
  754.      In a `reg', nonzero if it corresponds to a variable present in the
  755.      user's source code.  Zero for temporaries generated internally by
  756.      the compiler.  Stored in the `volatil' field and printed as `/v'.
  757.  
  758. `REG_FUNCTION_VALUE_P (X)'
  759.      Nonzero in a `reg' if it is the place in which this function's
  760.      value is going to be returned.  (This happens only in a hard
  761.      register.)  Stored in the `integrated' field and printed as `/i'.
  762.  
  763.      The same hard register may be used also for collecting the values
  764.      of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
  765.      in this kind of use.
  766.  
  767. `SUBREG_PROMOTED_VAR_P'
  768.      Nonzero in a `subreg' if it was made when accessing an object that
  769.      was promoted to a wider mode in accord with the `PROMOTED_MODE'
  770.      machine description macro (*note Storage Layout::.).  In this
  771.      case, the mode of the `subreg' is the declared mode of the object
  772.      and the mode of `SUBREG_REG' is the mode of the register that
  773.      holds the object.  Promoted variables are always either sign- or
  774.      zero-extended to the wider mode on every assignment.  Stored in
  775.      the `in_struct' field and printed as `/s'.
  776.  
  777. `SUBREG_PROMOTED_UNSIGNED_P'
  778.      Nonzero in a `subreg' that has `SUBREG_PROMOTED_VAR_P' nonzero if
  779.      the object being referenced is kept zero-extended and zero if it
  780.      is kept sign-extended.  Stored in the `unchanging' field and
  781.      printed as `/u'.
  782.  
  783. `RTX_UNCHANGING_P (X)'
  784.      Nonzero in a `reg' or `mem' if the value is not changed.  (This
  785.      flag is not set for memory references via pointers to constants.
  786.      Such pointers only guarantee that the object will not be changed
  787.      explicitly by the current function.  The object might be changed by
  788.      other functions or by aliasing.)  Stored in the `unchanging' field
  789.      and printed as `/u'.
  790.  
  791. `RTX_INTEGRATED_P (INSN)'
  792.      Nonzero in an insn if it resulted from an in-line function call.
  793.      Stored in the `integrated' field and printed as `/i'.  This may be
  794.      deleted; nothing currently depends on it.
  795.  
  796. `SYMBOL_REF_USED (X)'
  797.      In a `symbol_ref', indicates that X has been used.  This is
  798.      normally only used to ensure that X is only declared external
  799.      once.  Stored in the `used' field.
  800.  
  801. `SYMBOL_REF_FLAG (X)'
  802.      In a `symbol_ref', this is used as a flag for machine-specific
  803.      purposes.  Stored in the `volatil' field and printed as `/v'.
  804.  
  805. `LABEL_OUTSIDE_LOOP_P'
  806.      In `label_ref' expressions, nonzero if this is a reference to a
  807.      label that is outside the innermost loop containing the reference
  808.      to the label.  Stored in the `in_struct' field and printed as `/s'.
  809.  
  810. `INSN_DELETED_P (INSN)'
  811.      In an insn, nonzero if the insn has been deleted.  Stored in the
  812.      `volatil' field and printed as `/v'.
  813.  
  814. `INSN_ANNULLED_BRANCH_P (INSN)'
  815.      In an `insn' in the delay slot of a branch insn, indicates that an
  816.      annulling branch should be used.  See the discussion under
  817.      `sequence' below.  Stored in the `unchanging' field and printed as
  818.      `/u'.
  819.  
  820. `INSN_FROM_TARGET_P (INSN)'
  821.      In an `insn' in a delay slot of a branch, indicates that the insn
  822.      is from the target of the branch.  If the branch insn has
  823.      `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if
  824.      the branch is taken.  For annulled branches with this bit clear,
  825.      the insn should be executed only if the branch is not taken.
  826.      Stored in the `in_struct' field and printed as `/s'.
  827.  
  828. `CONSTANT_POOL_ADDRESS_P (X)'
  829.      Nonzero in a `symbol_ref' if it refers to part of the current
  830.      function's "constants pool".  These are addresses close to the
  831.      beginning of the function, and GNU CC assumes they can be addressed
  832.      directly (perhaps with the help of base registers).  Stored in the
  833.      `unchanging' field and printed as `/u'.
  834.  
  835. `CONST_CALL_P (X)'
  836.      In a `call_insn', indicates that the insn represents a call to a
  837.      const function.  Stored in the `unchanging' field and printed as
  838.      `/u'.
  839.  
  840. `LABEL_PRESERVE_P (X)'
  841.      In a `code_label', indicates that the label can never be deleted.
  842.      Labels referenced by a non-local goto will have this bit set.
  843.      Stored in the `in_struct' field and printed as `/s'.
  844.  
  845. `SCHED_GROUP_P (INSN)'
  846.      During instruction scheduling, in an insn, indicates that the
  847.      previous insn must be scheduled together with this insn.  This is
  848.      used to ensure that certain groups of instructions will not be
  849.      split up by the instruction scheduling pass, for example, `use'
  850.      insns before a `call_insn' may not be separated from the
  851.      `call_insn'.  Stored in the `in_struct' field and printed as `/s'.
  852.  
  853.    These are the fields which the above macros refer to:
  854.  
  855. `used'
  856.      Normally, this flag is used only momentarily, at the end of RTL
  857.      generation for a function, to count the number of times an
  858.      expression appears in insns.  Expressions that appear more than
  859.      once are copied, according to the rules for shared structure
  860.      (*note Sharing::.).
  861.  
  862.      In a `symbol_ref', it indicates that an external declaration for
  863.      the symbol has already been written.
  864.  
  865.      In a `reg', it is used by the leaf register renumbering code to
  866.      ensure that each register is only renumbered once.
  867.  
  868. `volatil'
  869.      This flag is used in `mem', `symbol_ref' and `reg' expressions and
  870.      in insns.  In RTL dump files, it is printed as `/v'.
  871.  
  872.      In a `mem' expression, it is 1 if the memory reference is volatile.
  873.      Volatile memory references may not be deleted, reordered or
  874.      combined.
  875.  
  876.      In a `symbol_ref' expression, it is used for machine-specific
  877.      purposes.
  878.  
  879.      In a `reg' expression, it is 1 if the value is a user-level
  880.      variable.  0 indicates an internal compiler temporary.
  881.  
  882.      In an insn, 1 means the insn has been deleted.
  883.  
  884. `in_struct'
  885.      In `mem' expressions, it is 1 if the memory datum referred to is
  886.      all or part of a structure or array; 0 if it is (or might be) a
  887.      scalar variable.  A reference through a C pointer has 0 because
  888.      the pointer might point to a scalar variable.  This information
  889.      allows the compiler to determine something about possible cases of
  890.      aliasing.
  891.  
  892.      In an insn in the delay slot of a branch, 1 means that this insn
  893.      is from the target of the branch.
  894.  
  895.      During instruction scheduling, in an insn, 1 means that this insn
  896.      must be scheduled as part of a group together with the previous
  897.      insn.
  898.  
  899.      In `reg' expressions, it is 1 if the register has its entire life
  900.      contained within the test expression of some loop.
  901.  
  902.      In `subreg' expressions, 1 means that the `subreg' is accessing an
  903.      object that has had its mode promoted from a wider mode.
  904.  
  905.      In `label_ref' expressions, 1 means that the referenced label is
  906.      outside the innermost loop containing the insn in which the
  907.      `label_ref' was found.
  908.  
  909.      In `code_label' expressions, it is 1 if the label may never be
  910.      deleted.  This is used for labels which are the target of
  911.      non-local gotos.
  912.  
  913.      In an RTL dump, this flag is represented as `/s'.
  914.  
  915. `unchanging'
  916.      In `reg' and `mem' expressions, 1 means that the value of the
  917.      expression never changes.
  918.  
  919.      In `subreg' expressions, it is 1 if the `subreg' references an
  920.      unsigned object whose mode has been promoted to a wider mode.
  921.  
  922.      In an insn, 1 means that this is an annulling branch.
  923.  
  924.      In a `symbol_ref' expression, 1 means that this symbol addresses
  925.      something in the per-function constants pool.
  926.  
  927.      In a `call_insn', 1 means that this instruction is a call to a
  928.      const function.
  929.  
  930.      In an RTL dump, this flag is represented as `/u'.
  931.  
  932. `integrated'
  933.      In some kinds of expressions, including insns, this flag means the
  934.      rtl was produced by procedure integration.
  935.  
  936.      In a `reg' expression, this flag indicates the register containing
  937.      the value to be returned by the current function.  On machines
  938.      that pass parameters in registers, the same register number may be
  939.      used for parameters as well, but this flag is not set on such uses.
  940.  
  941. 
  942. File: gcc.info,  Node: Machine Modes,  Next: Constants,  Prev: Flags,  Up: RTL
  943.  
  944. Machine Modes
  945. =============
  946.  
  947.    A machine mode describes a size of data object and the
  948. representation used for it.  In the C code, machine modes are
  949. represented by an enumeration type, `enum machine_mode', defined in
  950. `machmode.def'.  Each RTL expression has room for a machine mode and so
  951. do certain kinds of tree expressions (declarations and types, to be
  952. precise).
  953.  
  954.    In debugging dumps and machine descriptions, the machine mode of an
  955. RTL expression is written after the expression code with a colon to
  956. separate them.  The letters `mode' which appear at the end of each
  957. machine mode name are omitted.  For example, `(reg:SI 38)' is a `reg'
  958. expression with machine mode `SImode'.  If the mode is `VOIDmode', it
  959. is not written at all.
  960.  
  961.    Here is a table of machine modes.  The term "byte" below refers to an
  962. object of `BITS_PER_UNIT' bits (*note Storage Layout::.).
  963.  
  964. `QImode'
  965.      "Quarter-Integer" mode represents a single byte treated as an
  966.      integer.
  967.  
  968. `HImode'
  969.      "Half-Integer" mode represents a two-byte integer.
  970.  
  971. `PSImode'
  972.      "Partial Single Integer" mode represents an integer which occupies
  973.      four bytes but which doesn't really use all four.  On some
  974.      machines, this is the right mode to use for pointers.
  975.  
  976. `SImode'
  977.      "Single Integer" mode represents a four-byte integer.
  978.  
  979. `PDImode'
  980.      "Partial Double Integer" mode represents an integer which occupies
  981.      eight bytes but which doesn't really use all eight.  On some
  982.      machines, this is the right mode to use for certain pointers.
  983.  
  984. `DImode'
  985.      "Double Integer" mode represents an eight-byte integer.
  986.  
  987. `TImode'
  988.      "Tetra Integer" (?) mode represents a sixteen-byte integer.
  989.  
  990. `SFmode'
  991.      "Single Floating" mode represents a single-precision (four byte)
  992.      floating point number.
  993.  
  994. `DFmode'
  995.      "Double Floating" mode represents a double-precision (eight byte)
  996.      floating point number.
  997.  
  998. `XFmode'
  999.      "Extended Floating" mode represents a triple-precision (twelve
  1000.      byte) floating point number.  This mode is used for IEEE extended
  1001.      floating point.  On some systems not all bits within these bytes
  1002.      will actually be used.
  1003.  
  1004. `TFmode'
  1005.      "Tetra Floating" mode represents a quadruple-precision (sixteen
  1006.      byte) floating point number.
  1007.  
  1008. `CCmode'
  1009.      "Condition Code" mode represents the value of a condition code,
  1010.      which is a machine-specific set of bits used to represent the
  1011.      result of a comparison operation.  Other machine-specific modes
  1012.      may also be used for the condition code.  These modes are not used
  1013.      on machines that use `cc0' (see *note Condition Code::.).
  1014.  
  1015. `BLKmode'
  1016.      "Block" mode represents values that are aggregates to which none of
  1017.      the other modes apply.  In RTL, only memory references can have
  1018.      this mode, and only if they appear in string-move or vector
  1019.      instructions.  On machines which have no such instructions,
  1020.      `BLKmode' will not appear in RTL.
  1021.  
  1022. `VOIDmode'
  1023.      Void mode means the absence of a mode or an unspecified mode.  For
  1024.      example, RTL expressions of code `const_int' have mode `VOIDmode'
  1025.      because they can be taken to have whatever mode the context
  1026.      requires.  In debugging dumps of RTL, `VOIDmode' is expressed by
  1027.      the absence of any mode.
  1028.  
  1029. `SCmode, DCmode, XCmode, TCmode'
  1030.      These modes stand for a complex number represented as a pair of
  1031.      floating point values.  The floating point values are in `SFmode',
  1032.      `DFmode', `XFmode', and `TFmode', respectively.
  1033.  
  1034. `CQImode, CHImode, CSImode, CDImode, CTImode, COImode'
  1035.      These modes stand for a complex number represented as a pair of
  1036.      integer values.  The integer values are in `QImode', `HImode',
  1037.      `SImode', `DImode', `TImode', and `OImode', respectively.
  1038.  
  1039.    The machine description defines `Pmode' as a C macro which expands
  1040. into the machine mode used for addresses.  Normally this is the mode
  1041. whose size is `BITS_PER_WORD', `SImode' on 32-bit machines.
  1042.  
  1043.    The only modes which a machine description must support are
  1044. `QImode', and the modes corresponding to `BITS_PER_WORD',
  1045. `FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'.  The compiler will attempt to
  1046. use `DImode' for 8-byte structures and unions, but this can be
  1047. prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'.
  1048. Alternatively, you can have the compiler use `TImode' for 16-byte
  1049. structures and unions.  Likewise, you can arrange for the C type `short
  1050. int' to avoid using `HImode'.
  1051.  
  1052.    Very few explicit references to machine modes remain in the compiler
  1053. and these few references will soon be removed.  Instead, the machine
  1054. modes are divided into mode classes.  These are represented by the
  1055. enumeration type `enum mode_class' defined in `machmode.h'.  The
  1056. possible mode classes are:
  1057.  
  1058. `MODE_INT'
  1059.      Integer modes.  By default these are `QImode', `HImode', `SImode',
  1060.      `DImode', and `TImode'.
  1061.  
  1062. `MODE_PARTIAL_INT'
  1063.      The "partial integer" modes, `PSImode' and `PDImode'.
  1064.  
  1065. `MODE_FLOAT'
  1066.      floating point modes.  By default these are `SFmode', `DFmode',
  1067.      `XFmode' and `TFmode'.
  1068.  
  1069. `MODE_COMPLEX_INT'
  1070.      Complex integer modes.  (These are not currently implemented).
  1071.  
  1072. `MODE_COMPLEX_FLOAT'
  1073.      Complex floating point modes.  By default these are `SCmode',
  1074.      `DCmode', `XCmode', and `TCmode'.
  1075.  
  1076. `MODE_FUNCTION'
  1077.      Algol or Pascal function variables including a static chain.
  1078.      (These are not currently implemented).
  1079.  
  1080. `MODE_CC'
  1081.      Modes representing condition code values.  These are `CCmode' plus
  1082.      any modes listed in the `EXTRA_CC_MODES' macro.  *Note Jump
  1083.      Patterns::, also see *Note Condition Code::.
  1084.  
  1085. `MODE_RANDOM'
  1086.      This is a catchall mode class for modes which don't fit into the
  1087.      above classes.  Currently `VOIDmode' and `BLKmode' are in
  1088.      `MODE_RANDOM'.
  1089.  
  1090.    Here are some C macros that relate to machine modes:
  1091.  
  1092. `GET_MODE (X)'
  1093.      Returns the machine mode of the RTX X.
  1094.  
  1095. `PUT_MODE (X, NEWMODE)'
  1096.      Alters the machine mode of the RTX X to be NEWMODE.
  1097.  
  1098. `NUM_MACHINE_MODES'
  1099.      Stands for the number of machine modes available on the target
  1100.      machine.  This is one greater than the largest numeric value of any
  1101.      machine mode.
  1102.  
  1103. `GET_MODE_NAME (M)'
  1104.      Returns the name of mode M as a string.
  1105.  
  1106. `GET_MODE_CLASS (M)'
  1107.      Returns the mode class of mode M.
  1108.  
  1109. `GET_MODE_WIDER_MODE (M)'
  1110.      Returns the next wider natural mode.  For example, the expression
  1111.      `GET_MODE_WIDER_MODE (QImode)' returns `HImode'.
  1112.  
  1113. `GET_MODE_SIZE (M)'
  1114.      Returns the size in bytes of a datum of mode M.
  1115.  
  1116. `GET_MODE_BITSIZE (M)'
  1117.      Returns the size in bits of a datum of mode M.
  1118.  
  1119. `GET_MODE_MASK (M)'
  1120.      Returns a bitmask containing 1 for all bits in a word that fit
  1121.      within mode M.  This macro can only be used for modes whose
  1122.      bitsize is less than or equal to `HOST_BITS_PER_INT'.
  1123.  
  1124. `GET_MODE_ALIGNMENT (M))'
  1125.      Return the required alignment, in bits, for an object of mode M.
  1126.  
  1127. `GET_MODE_UNIT_SIZE (M)'
  1128.      Returns the size in bytes of the subunits of a datum of mode M.
  1129.      This is the same as `GET_MODE_SIZE' except in the case of complex
  1130.      modes.  For them, the unit size is the size of the real or
  1131.      imaginary part.
  1132.  
  1133. `GET_MODE_NUNITS (M)'
  1134.      Returns the number of units contained in a mode, i.e.,
  1135.      `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'.
  1136.  
  1137. `GET_CLASS_NARROWEST_MODE (C)'
  1138.      Returns the narrowest mode in mode class C.
  1139.  
  1140.    The global variables `byte_mode' and `word_mode' contain modes whose
  1141. classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or
  1142. `BITS_PER_WORD', respectively.  On 32-bit machines, these are `QImode'
  1143. and `SImode', respectively.
  1144.  
  1145.